Checklist: CR Analysis Checklist
This guideline purpose is to describe how the change analysis should be performed.
Relationships
Related Elements
Main Description

Every change request must be analysed before implemented. The group responsible for the analysis is called CCB (Change Control Board), and the CCB can be formed by different roles and persons.

Some of the purpose of this anaylsis, amon others, are:

1) Priorization of Changes. 
2) Identification of each change's impacts.
3) Identify similaties between the changes requested and Group changes regarding its similarity.
4) Guarantee that changes feedbacks are being implemented.

Based on those purposes, the change analysis must be performed following a specific checklist of what to analyse and what to do in order to be effective in the change analysis and not to spend too much time on this analysis.

The checklist defined to be follwed is attached as a guide in this page.

Ideally, the analysis made has to be documented somewhere, and one of the best places to document it is inside the CR being analysed. The CCB is then responsible to generate the documentation of the analysis following the template defined and post it in the CR it can be reviewed in the future (in case of similar changes) and may serve as the rationale for each changes implementation.



www.processimpact.com/

Implications of the Proposed Change

Check Items
Identify any existing requirements in the baseline that conflict with the proposed change.
Identify any other pending requirement changes that conflict with the proposed change.
What are the consequences of not making the change?
What are possible adverse side effects or other risks of making the proposed change?
Will the proposed change adversely affect performance requirements or other quality attributes?
Is the proposed change feasible within known technical constraints and current staff skills?
Identify any third party software that must be purchased.
How will the proposed change affect the sequence, dependencies, effort, or duration of any tasks currently in the project schedule?
Will prototyping or other user input be required to verify the proposed change?
How much effort that has already been invested in the project will be lost if this change is accepted?
Will the proposed change cause an increase in product unit cost, such as by increasing third-party product licensing fees?
Identify any user interface changes, additions, or deletions required.
Identify any changes, additions, or deletions required in reports, databases, or data files.
Identify the design components that must be created, modified, or deleted.
Identify hardware components that must be added, altered, or deleted.
Identify the source code files that must be created, modified, or deleted.
Identify any changes required in build files.
Identify existing unit, integration, system, and acceptance test cases that must be modified or deleted.
Estimate the number of new unit, integration, system, and acceptance test cases that will be required.
Identify any help screens, user manuals, training materials, or other documentation that must be created or modified.
Identify any other systems, applications, libraries, or hardware components affected by the change.
Identify Plans impact
Identify any impact the proposed change will have on the project’s software project management plan, software quality assurance plan, software configuration management plan, or other plans.
Identify any impact the proposed change will have on fielded systems if the affected component is not perfectly backward compatible.